IRIX Base Documentation 1998 November

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Base Documentation 1998 November / IRIX 6.5.2 Base Documentation November 1998.img / usr / share / catman / u_man / cat3 / Tcl / incrTcl.z / incrTcl

Wrap

Text File | 1998-10-30 | 44KB | 659 lines

iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) NNNNAAAAMMMMEEEE incrTcl - Object-oriented extensions to Tcl SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS iiiittttccccllll____ccccllllaaaassssssss _c_l_a_s_s_N_a_m_e {{{{ iiiinnnnhhhheeeerrrriiiitttt _b_a_s_e_C_l_a_s_s ?_b_a_s_e_C_l_a_s_s...? ccccoooonnnnssssttttrrrruuuuccccttttoooorrrr _a_r_g_s _b_o_d_y ddddeeeessssttttrrrruuuuccccttttoooorrrr _b_o_d_y mmmmeeeetttthhhhoooodddd _n_a_m_e _a_r_g_s _b_o_d_y pppprrrroooocccc _n_a_m_e _a_r_g_s _b_o_d_y ppppuuuubbbblllliiiicccc _v_a_r_N_a_m_e ?_i_n_i_t? ?_c_o_n_f_i_g? pppprrrrooootttteeeecccctttteeeedddd _v_a_r_N_a_m_e ?_i_n_i_t? ccccoooommmmmmmmoooonnnn _v_a_r_N_a_m_e ?_i_n_i_t? }}}} _c_l_a_s_s_N_a_m_e _o_b_j_N_a_m_e ?_a_r_g_s...? _c_l_a_s_s_N_a_m_e ####aaaauuuuttttoooo ?_a_r_g_s...? _c_l_a_s_s_N_a_m_e :::::::: _p_r_o_c ?_a_r_g_s...? _o_b_j_N_a_m_e _m_e_t_h_o_d ?_a_r_g_s...? iiiittttccccllll____iiiinnnnffffoooo ccccllllaaaasssssssseeeessss ????_p_a_t_t_e_r_n? iiiittttccccllll____iiiinnnnffffoooo oooobbbbjjjjeeeeccccttttssss ????_p_a_t_t_e_r_n? ?----ccccllllaaaassssssss _c_l_a_s_s_N_a_m_e? ?----iiiissssaaaa _c_l_a_s_s_N_a_m_e? _C_o_m_m_a_n_d_s _a_v_a_i_l_a_b_l_e _w_i_t_h_i_n _c_l_a_s_s _m_e_t_h_o_d_s/_p_r_o_c_s: gggglllloooobbbbaaaallll _v_a_r_N_a_m_e ?_v_a_r_N_a_m_e...? pppprrrreeeevvvviiiioooouuuussss _c_o_m_m_a_n_d ?_a_r_g_s...? vvvviiiirrrrttttuuuuaaaallll _c_o_m_m_a_n_d ?_a_r_g_s...? DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN [[[[iiiinnnnccccrrrr TTTTccccllll]]]] provides object-oriented extensions to Tcl, much as C++ provides object-oriented extensions to C. The emphasis of this work, however, is not to create a whiz-bang object-oriented programming environment. Rather, it is to support more structured programming practices in Tcl without changing the flavor of the language. More than anything else, [[[[iiiinnnnccccrrrr TTTTccccllll]]]] provides a means of encapsulating related procedures together with their shared data in a local namespace that is hidden from the outside world. It encourages better programming by promoting the object-oriented "library" mindset. It also allows for code re-use through inheritance. The fundamental construct in [[[[iiiinnnnccccrrrr TTTTccccllll]]]] is the class definition. Each class acts as a template for actual objects that can be created. Each object in a class contains a unique bundle of data, including "public" and "protected" data members. When execution takes place within the scope of the class, both types of data members are accessible. To the programmer working outside of the class scope-using an object to build his application-only public data members are accessible. Public members represent attributes that can be used to configure an object. For example, the "-text" attribute in the usual Tk "bbbbuuuuttttttttoooonnnn" widget could be PPPPaaaaggggeeee 1111 iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) thought of as a public member. Protected members, on the other hand, reflect the inner workings of an object and are kept hidden from the outside world. This insulates the programmer that uses a class from the details of its implementation. Classes can also define "common" data members that are shared by all objects in a class. Like protected members, common members are only accessible within the scope of the class. The class designer will often provide special class-level procedures or "procs" to manipulate common members. Since these "procs" can be invoked without reference to any specific object, they have access to common members, but not to public or protected members. Special procedures called "methods" are used to manipulate individual objects. The use of methods should be familiar to any Tk programmer-the "bbbbuuuuttttttttoooonnnn" widget, for example, has methods such as "flash" and "invoke" that are used to control its behavior. These methods form a contract between the class designer and the application developer, completely specifying the list of functions that can be used to interact with objects in the class. The implementation details within each method, however, are left solely to the class designer. The public interface says _w_h_a_t an object will do but not _h_o_w it will do it. Insulating the application developer from these details leaves the class designer free to change them at any time, without warning, and without affecting programs that rely on the class. It is precisely this encapsulation that makes object-oriented programs easier to understand and maintain. The fact that [[[[iiiinnnnccccrrrr TTTTccccllll]]]] objects look like Tk widgets is no accident. [[[[iiiinnnnccccrrrr TTTTccccllll]]]] was designed this way, to blend naturally into a Tcl/Tk application. But [[[[iiiinnnnccccrrrr TTTTccccllll]]]] extends the Tk paradigm from being merely object-based to being fully object-oriented. An object-oriented system supports inheritance, allowing classes to share common behaviors by inheriting them from an ancestor or base class. Having a base class as a common abstraction allows a programmer to treat related classes in a similar manner. For example, a toaster and a blender perform different (specialized) functions, but both share the abstraction of being appliances. By abstracting common behaviors into a base class, code can be _s_h_a_r_e_d rather than _c_o_p_i_e_d. The resulting application is easier to understand and maintain, and derived classes (e.g., specialized appliances) can be added or removed more easily. This description was merely a brief overview of object-oriented programming and [[[[iiiinnnnccccrrrr TTTTccccllll]]]]. A more tutorial introduction is presented in the paper included with this distribution. Further details are presented in reference form below. SSSSCCCCOOOOPPPPEEEE Each class maintains its own local scope, separate from the main interpreter. Within the scope of a class, all members-including methods and procs, as well as public, protected and common variables-can be accessed transparently. In other words, methods and procs can be used like ordinary commands, and variables can be used without declaring them with anything like the Tcl "gggglllloooobbbbaaaallll" command. PPPPaaaaggggeeee 2222 iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) The scope of a class extends to all derived classes as well, so members can be accessed transparently throughout a derivation hierarchy. If the same member name appears more than once in the hierarchy, the class with highest priority gets transparent access to the simple member name, and all other members must be accessed using the explicit "_c_l_a_s_s::_m_e_m_b_e_r" syntax. Priority is determined by the list of classes as reported by the "iiiinnnnffffoooo hhhheeeerrrriiiittttaaaaggggeeee" command. If a command is not recognized in a particular class scope, it is passed up the derivation hierarchy for evaluation. Again, base classes are consulted in the order reported by the "iiiinnnnffffoooo hhhheeeerrrriiiittttaaaaggggeeee" command. If a command is not recognized by any class in the hierarchy, it is passed out to the global scope (main interpreter) for evaluation. This scheme allows Tk widget commands, for example, to be accessed transparently within any class, but to be executed (as they should be) in the global scope. Any command can be sent explicitly to the global scope using the "::_c_o_m_m_a_n_d" syntax. It is sometimes convenient, particularly when dealing with Tk widgets, to have access to global variables that exist in the main interpreter. This is achieved using the usual Tcl "gggglllloooobbbbaaaallll" command within a class method or proc. AAAARRRRGGGGUUUUMMMMEEEENNNNTTTT LLLLIIIISSSSTTTTSSSS Class methods and procs look like ordinary Tcl procs, except that they also provide transparent access to class data. The rules for handling formal arguments in the _a_r_g_s lists are the same as well. Each element of this list can be a simple argument name, or another list containing the argument name and its default value. If the last formal argument is named "args", it will absorb all unmatched arguments into a single list of values. Argument lists for class methods also recognize a special argument to handle configuration of public variables. If the last formal argument is named "config", it will absorb all unmatched arguments and parse them as "-_v_a_r_N_a_m_e _v_a_l_u_e" assignments. If _v_a_r_N_a_m_e is recognized as a public variable, then this variable is modified to contain the given value. If the variable was defined with special _c_o_n_f_i_g code, this code is automatically executed in the scope of its associated class. If this _c_o_n_f_i_g code returns an error, the variable is automatically reset to its previous value, and the method is aborted, returning the configuration error. If argument parsing is successful, the "config" variable is set to the list of variables that were configured, and the method body is executed. As an example, suppose that we define a simple class with two public variables: _iiii_tttt_cccc_llll______cccc_llll_aaaa_ssss_ssss _TTTT_hhhh_iiii_nnnn_gggg _{{{{ _cccc_oooo_nnnn_ssss_tttt_rrrr_uuuu_cccc_tttt_oooo_rrrr _{{{{_cccc_oooo_nnnn_ffff_iiii_gggg_}}}} _{{{{_}}}} _mmmm_eeee_tttt_hhhh_oooo_dddd _cccc_oooo_nnnn_ffff_iiii_gggg_uuuu_rrrr_eeee _{{{{_cccc_oooo_nnnn_ffff_iiii_gggg_}}}} _{{{{_}}}} PPPPaaaaggggeeee 3333 iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) _pppp_uuuu_bbbb_llll_iiii_cccc _ffff_oooo_oooo _""""_"""" _{{{{ _pppp_uuuu_tttt_ssss _ssss_tttt_dddd_oooo_uuuu_tttt _""""_----_---- _jjjj_uuuu_ssss_tttt _mmmm_oooo_dddd_iiii_ffff_iiii_eeee_dddd _ffff_oooo_oooo_:::: _$$$$_ffff_oooo_oooo_"""" _}}}} _pppp_uuuu_bbbb_llll_iiii_cccc _bbbb_aaaa_rrrr _""""_"""" _{{{{ _pppp_uuuu_tttt_ssss _ssss_tttt_dddd_oooo_uuuu_tttt _""""_----_---- _jjjj_uuuu_ssss_tttt _mmmm_oooo_dddd_iiii_ffff_iiii_eeee_dddd _bbbb_aaaa_rrrr_:::: _$$$$_bbbb_aaaa_rrrr_"""" _}}}} _}}}} Both the constructor and the "configure" method contain the special "config" formal argument. Thus, either of these methods can be used to configure the public variables: _wwww_iiii_ssss_hhhh_:::: _TTTT_hhhh_iiii_nnnn_gggg _xxxx _----_ffff_oooo_oooo _1111 _----_bbbb_aaaa_rrrr _2222 _----_---- _jjjj_uuuu_ssss_tttt _mmmm_oooo_dddd_iiii_ffff_iiii_eeee_dddd _ffff_oooo_oooo_:::: _1111 _----_---- _jjjj_uuuu_ssss_tttt _mmmm_oooo_dddd_iiii_ffff_iiii_eeee_dddd _bbbb_aaaa_rrrr_:::: _2222 _xxxx _wwww_iiii_ssss_hhhh_:::: _xxxx _cccc_oooo_nnnn_ffff_iiii_gggg_uuuu_rrrr_eeee _----_bbbb_aaaa_rrrr _3333 _----_---- _jjjj_uuuu_ssss_tttt _mmmm_oooo_dddd_iiii_ffff_iiii_eeee_dddd _bbbb_aaaa_rrrr_:::: _3333 Each time "foo" or "bar" is configured in this example, its special _c_o_n_f_i_g code (last argument in the "public" declaration) is executed, printing a message to show the updated value. CCCCLLLLAAAASSSSSSSS DDDDEEEEFFFFIIIINNNNIIIITTTTIIIIOOOONNNNSSSS iiiittttccccllll____ccccllllaaaassssssss _c_l_a_s_s_N_a_m_e _d_e_f_i_n_i_t_i_o_n Provides the definition for a class named _c_l_a_s_s_N_a_m_e. If _c_l_a_s_s_N_a_m_e is already defined, then this command returns an error. If the class definition is successfully parsed, _c_l_a_s_s_N_a_m_e becomes a command in the interpreter, handling the creation of objects and providing access to class scope. The class _d_e_f_i_n_i_t_i_o_n is evaluated as a series of Tcl statements that configure the interpreter managing a particular class scope. In addition to the usual commands, the following class definition commands are recognized: iiiinnnnhhhheeeerrrriiiitttt _b_a_s_e_C_l_a_s_s ?_b_a_s_e_C_l_a_s_s...? Declares one or more base classes, causing the current class to inherit their characteristics. Classes must have been defined by a previous "iiiittttccccllll____ccccllllaaaassssssss" command, or must be available to the auto-loading facility (see "AUTO-LOADING" below). A single class definition can contain no more than one "iiiinnnnhhhheeeerrrriiiitttt" command. When the same member name appears in two or more base classes, the base class that appears first in the "iiiinnnnhhhheeeerrrriiiitttt" list takes precedence. For example, if classes "Foo" and "Bar" both contain the member "x", then the "iiiinnnnhhhheeeerrrriiiitttt" statement: _iiii_nnnn_hhhh_eeee_rrrr_iiii_tttt _FFFF_oooo_oooo _BBBB_aaaa_rrrr allows "Foo::x" to be accessed simply as "x" but forces "Bar::x" (and all other inherited members named "x") to be referenced with their explicit "_c_l_a_s_s::_m_e_m_b_e_r" name. ccccoooonnnnssssttttrrrruuuuccccttttoooorrrr _a_r_g_s _b_o_d_y Declares the argument list and body used for the constructor, which is automatically invoked whenever an object is created. If construction is successful, the constructor always returns the object name-regardless of how the _b_o_d_y is defined-and the object name becomes a command in the main interpreter. If construction fails, an error message is returned. PPPPaaaaggggeeee 4444 iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) Like any other method, the constructor can be inherited from a base class. Furthermore, any base class constructor that is not explicitly invoked within _b_o_d_y will be implicitly invoked by [[[[iiiinnnnccccrrrr TTTTccccllll]]]] in the order that the base classes are reported in the "iiiinnnnffffoooo hhhheeeerrrriiiittttaaaaggggeeee" command. This ensures that all base classes are properly constructed. ddddeeeessssttttrrrruuuuccccttttoooorrrr _b_o_d_y Declares the body used for the destructor, which is automatically invoked whenever an object is deleted. If the destructor is successful, the object data is destroyed and the object name is removed as a command from the main interpreter. If destruction fails, an error message is returned and the object remains. Like any other method, the destructor can be inherited from a base class. Furthermore, any base class destructor that is not explicitly invoked within _b_o_d_y will be implicitly invoked by [[[[iiiinnnnccccrrrr TTTTccccllll]]]], in the _r_e_v_e_r_s_e order compared to constructors. mmmmeeeetttthhhhoooodddd _n_a_m_e _a_r_g_s _b_o_d_y Declares a method called _n_a_m_e with an argument list _a_r_g_s and a _b_o_d_y of Tcl statements. A method is just like the usual Tcl "proc" except that it has transparent access to public, protected and common variables. Within the class scope, a method can be invoked like any other command-simply by using its name. In the external interpreter, the method name must be prefaced by an object name. Methods in a base class that are redefined in the current class or hidden by another base class can be explicitly scoped using the "_c_l_a_s_s::_m_e_t_h_o_d" syntax. pppprrrroooocccc _n_a_m_e _a_r_g_s _b_o_d_y Declares a proc called _n_a_m_e with an argument list _a_r_g_s and a _b_o_d_y of Tcl statements. A proc is similar to a method, except that it can be invoked without referring to a specific object, and therefore has access only to common variables-not to public or protected variables. Within the class scope, a proc can be invoked like any other command-simply by using its name. In the external interpreter, the proc is invoked using the _c_l_a_s_s_N_a_m_e command "_c_l_a_s_s_N_a_m_e :: _p_r_o_c" to access the class scope (see below). Procs in a base class that are redefined in the current class or hidden by another base class can be explicitly scoped using the "_c_l_a_s_s::_p_r_o_c" syntax. ppppuuuubbbblllliiiicccc _v_a_r_N_a_m_e ?_i_n_i_t? ?_c_o_n_f_i_g? Declares a public variable named _v_a_r_N_a_m_e. Public variables are visible in methods within the scope of their class and any derived class. In addition, they can be modified outside of the class scope using the special "config" formal argument (see "ARGUMENT LISTS" above). If the optional _i_n_i_t is specified, it is used as the initial value of the variable when a new object is created. If the optional _c_o_n_f_i_g command is specified, it is PPPPaaaaggggeeee 5555 iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) invoked whenever a public variable is modified via the "config" formal argument; if the _c_o_n_f_i_g command returns an error, the public variable is reset to its value before configuration, and the method handling the configuration returns an error. pppprrrrooootttteeeecccctttteeeedddd _v_a_r_N_a_m_e ?_i_n_i_t? Declares a protected variable named _v_a_r_N_a_m_e. Protected variables are visible in methods within the scope of their class and any derived class, but cannot be modified outside of the class scope. If the optional _i_n_i_t is specified, it is used as the initial value of the variable when a new object is created. Initialization forces the variable to be a simple scalar value; uninitialized variables, on the other hand, can be used as arrays. All objects have a built-in protected variable named "this" which is initialized to the instance name for the object. ccccoooommmmmmmmoooonnnn _v_a_r_N_a_m_e ?_i_n_i_t? Declares a common variable named _v_a_r_N_a_m_e. Common variables are shared among all objects in a class. They are visible in methods and procs in the scope of their class and any derived class, but cannot be modified outside of the class scope. If the optional _i_n_i_t is specified, it is used as the initial value of the variable. Initialization forces the variable to be a simple scalar value; uninitialized variables, on the other hand, can be used as arrays. Once a common variable has been declared, it can be configured using ordinary Tcl code within the class definition. This facility is particularly useful when the initialization of the variable is non-trivial - when the variable contains an array of values, for example: _iiii_tttt_cccc_llll______cccc_llll_aaaa_ssss_ssss _FFFF_oooo_oooo _{{{{ _.... _.... _cccc_oooo_mmmm_mmmm_oooo_nnnn _bbbb_oooo_oooo_llll_eeee_aaaa_nnnn _ssss_eeee_tttt _bbbb_oooo_oooo_llll_eeee_aaaa_nnnn_((((_tttt_rrrr_uuuu_eeee_)))) _1111 _ssss_eeee_tttt _bbbb_oooo_oooo_llll_eeee_aaaa_nnnn_((((_ffff_aaaa_llll_ssss_eeee_)))) _0000 _}}}} CCCCLLLLAAAASSSSSSSS UUUUSSSSAAAAGGGGEEEE When a class definition has been loaded (or made available to the auto- loader), it can be used as a command in the main interpreter: _c_l_a_s_s_N_a_m_e _o_b_j_N_a_m_e ?_a_r_g_s...? Creates a new object in class _c_l_a_s_s_N_a_m_e with the name _o_b_j_N_a_m_e. Remaining arguments are passed to the constructor. If construction is successful, the object name is returned and this name becomes a command in the main interpreter. Otherwise, an error is returned. PPPPaaaaggggeeee 6666 iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) _c_l_a_s_s_N_a_m_e #auto ?_a_r_g_s...? Creates a new object in class _c_l_a_s_s_N_a_m_e with an automatically generated name. Names are of the form _c_l_a_s_s_N_a_m_e<_n_u_m_b_e_r>, e.g., Toaster0, Toaster1, etc. Remaining arguments are passed to the constructor. If construction is successful, the object name is returned and this name becomes a command in the main interpreter. Otherwise, an error is returned. _c_l_a_s_s_N_a_m_e :: _p_r_o_c ?_a_r_g_s...? Used at the global scope to invoke a class proc named _p_r_o_c. Class procs are like ordinary Tcl procs, except that they are executed in the scope of the class and therefore have transparent access to common data members. Notice that, unlike any other scope qualifier in [[[[iiiinnnnccccrrrr TTTTccccllll]]]], the "::" shown above is surrounded by spaces. This is necessary to avoid polluting the global namespace with every possible "_c_l_a_s_s::_p_r_o_c" command. In Release 1.1, a special version of the | usual "unknown" proc was provided to recognize commands like | "_c_l_a_s_s::_p_r_o_c" (without spaces around the "::" qualifier). This | facility was unpopular, and is no longer supported. When class | procs are invoked from the main interpreter, the "::" qualifier must| be surrounded by spaces. OOOOBBBBJJJJEEEECCCCTTTT UUUUSSSSAAAAGGGGEEEE _o_b_j_N_a_m_e _m_e_t_h_o_d ?_a_r_g_s...? Invokes a method named _m_e_t_h_o_d to operate on the specified object. Remaining arguments are passed to the method. The method name can be "constructor", "destructor", any method name appearing in the class definition, or any of the following built-in methods. BBBBUUUUIIIILLLLTTTT----IIIINNNN MMMMEEEETTTTHHHHOOOODDDDSSSS _o_b_j_N_a_m_e iiiissssaaaa _c_l_a_s_s_N_a_m_e Returns non-zero if the given _c_l_a_s_s_N_a_m_e can be found in the object's heritage, and zero otherwise. _o_b_j_N_a_m_e ddddeeeelllleeeetttteeee Invokes the destructor associated with an object. If the destructor is successful, data associated with the object is deleted and _o_b_j_N_a_m_e is removed from the commands in the main interpreter. Returns the empty string, regardless of the destructor body. _o_b_j_N_a_m_e iiiinnnnffffoooo _o_p_t_i_o_n ?_a_r_g_s...? _c_l_a_s_s_N_a_m_e :: iiiinnnnffffoooo _o_p_t_i_o_n ?_a_r_g_s...? Returns information related to the class definition, or information concerning the interpreter that implements the class scope. The _o_p_t_i_o_n parameter includes the following things, as well as the options recognized by the usual Tcl "info" command: PPPPaaaaggggeeee 7777 iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) _o_b_j_N_a_m_e iiiinnnnffffoooo ccccllllaaaassssssss Returns the class name at the current class scope. When prefaced by the object name, this command executes in the most-specific class scope, and therefore returns the most- specific class name. _o_b_j_N_a_m_e iiiinnnnffffoooo iiiinnnnhhhheeeerrrriiiitttt Returns the list of base classes as they were defined in the "iiiinnnnhhhheeeerrrriiiitttt" command, or an empty string if this is a top-level class. _o_b_j_N_a_m_e iiiinnnnffffoooo hhhheeeerrrriiiittttaaaaggggeeee Returns the current class name and the entire list of base classes in the order that they are traversed for object construction or member lookup. _o_b_j_N_a_m_e iiiinnnnffffoooo mmmmeeeetttthhhhoooodddd _o_b_j_N_a_m_e iiiinnnnffffoooo mmmmeeeetttthhhhoooodddd _m_e_t_h_o_d_N_a_m_e ?----aaaarrrrggggssss? ?----bbbbooooddddyyyy? In the first form, this command returns a list of all class methods. In the second form, it returns information for a specific method. If neither of the optional ----aaaarrrrggggssss or ----bbbbooooddddyyyy flags is specified, a complete method definition is returned as a list of three elements including the method name, argument list and body. Otherwise, the requested information is returned without the method name. If the _m_e_t_h_o_d_N_a_m_e is not recognized, an empty string is returned. _o_b_j_N_a_m_e iiiinnnnffffoooo pppprrrroooocccc _o_b_j_N_a_m_e iiiinnnnffffoooo pppprrrroooocccc _p_r_o_c_N_a_m_e ?----aaaarrrrggggssss? ?----bbbbooooddddyyyy? In the first form, this command returns a list of all class procs. In the second form, it returns information for a specific proc. If neither of the optional ----aaaarrrrggggssss or ----bbbbooooddddyyyy flags is specified, a complete proc definition is returned as a list of three elements including the proc name, argument list and body. Otherwise, the requested information is returned without the proc name. If the _p_r_o_c_N_a_m_e is not recognized, an empty string is returned. _o_b_j_N_a_m_e iiiinnnnffffoooo ppppuuuubbbblllliiiicccc _o_b_j_N_a_m_e iiiinnnnffffoooo ppppuuuubbbblllliiiicccc _v_a_r_N_a_m_e ?----iiiinnnniiiitttt? ?----vvvvaaaalllluuuueeee? ?----ccccoooonnnnffffiiiigggg? In the first form, this command returns a list of all public variables. In the second form, it returns information for a specific public variable. If none of the optional ----iiiinnnniiiitttt, ----vvvvaaaalllluuuueeee or ----ccccoooonnnnffffiiiigggg flags are specified, all available information is returned as a list of four elements including the variable name, initial value, current value, and configuration commands. Otherwise, the requested information is returned without the variable name. If the _v_a_r_N_a_m_e is not recognized, an empty string is returned. PPPPaaaaggggeeee 8888 iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) _o_b_j_N_a_m_e iiiinnnnffffoooo pppprrrrooootttteeeecccctttteeeedddd _o_b_j_N_a_m_e iiiinnnnffffoooo pppprrrrooootttteeeecccctttteeeedddd _v_a_r_N_a_m_e ?----iiiinnnniiiitttt? ?----vvvvaaaalllluuuueeee? In the first form, this command returns a list of all protected variables. In the second form, it returns information for a specific protected variable. If neither of the optional ----iiiinnnniiiitttt or ----vvvvaaaalllluuuueeee flags is specified, all available information is returned as a list of three elements including the variable name, initial value and current value. Otherwise, the requested information is returned without the variable name. If the _v_a_r_N_a_m_e is not recognized, an empty string is returned. _o_b_j_N_a_m_e iiiinnnnffffoooo ccccoooommmmmmmmoooonnnn _o_b_j_N_a_m_e iiiinnnnffffoooo ccccoooommmmmmmmoooonnnn _v_a_r_N_a_m_e ?----iiiinnnniiiitttt? ?----vvvvaaaalllluuuueeee? In the first form, this command returns a list of all common variables. In the second form, it returns information for a specific common variable. If neither of the optional ----iiiinnnniiiitttt or ----vvvvaaaalllluuuueeee flags is specified, all available information is returned as a list of three elements including the variable name, initial value and current value. Otherwise, the requested information is returned without the variable name. If the _v_a_r_N_a_m_e is not recognized, an empty string is returned. CCCCLLLLAAAASSSSSSSS////OOOOBBBBJJJJEEEECCCCTTTT IIIINNNNFFFFOOOORRRRMMMMAAAATTTTIIIIOOOONNNN The following commands are available at the global scope to query information about classes and objects that have been created. iiiittttccccllll____iiiinnnnffffoooo ccccllllaaaasssssssseeeessss ????_p_a_t_t_e_r_n? Returns a list of classes with names matching the string _p_a_t_t_e_r_n according to the rules of the "ssssttttrrrriiiinnnngggg mmmmaaaattttcccchhhh" command. If _p_a_t_t_e_r_n is not specified, returns a list of all known classes. iiiittttccccllll____iiiinnnnffffoooo oooobbbbjjjjeeeeccccttttssss ????_p_a_t_t_e_r_n? ?----ccccllllaaaassssssss _c_l_a_s_s_N_a_m_e? ?----iiiissssaaaa _c_l_a_s_s_N_a_m_e? Returns a list of objects with names matching the string _p_a_t_t_e_r_n according to the rules of the "ssssttttrrrriiiinnnngggg mmmmaaaattttcccchhhh" command. If _p_a_t_t_e_r_n is not specified, return a list of all known objects. If the "----ccccllllaaaassssssss" parameter is specified, this list is restricted to objects whose most-specific class is _c_l_a_s_s_N_a_m_e. If the "----iiiissssaaaa" parameter is specified, this list is further restricted to objects having the given _c_l_a_s_s_N_a_m_e anywhere in their heritage. OOOOTTTTHHHHEEEERRRR BBBBUUUUIIIILLLLTTTT----IIIINNNN CCCCOOOOMMMMMMMMAAAANNNNDDDDSSSS The following commands are also available within the scope of each class. They cannot be accessed from outside of the class as proper methods or procs; rather, they are useful inside the class when implementing its functionality. gggglllloooobbbbaaaallll _v_a_r_N_a_m_e ?_v_a_r_N_a_m_e...? Creates a link to one or more global variables in the main interpreter. This is useful when communicating with Tk widgets that rely on global variables. PPPPaaaaggggeeee 9999 iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) iiiinnnnccccrrrrTTTTccccllll((((3333TTTTccccllll)))) pppprrrreeeevvvviiiioooouuuussss _c_o_m_m_a_n_d ?_a_r_g_s...? Invokes _c_o_m_m_a_n_d in the scope of the most immediate base class (i.e.,| the "previous" class) for the object. For classes using single inheritance, this facility can be used to avoid hard-wired base class references of the form "_c_l_a_s_s::_c_o_m_m_a_n_d", making code easier to maintain. For classes using multiple inheritance, the utility of this function is dubious. If the class at the relevant scope has no base class, an error is returned. vvvviiiirrrrttttuuuuaaaallll _c_o_m_m_a_n_d ?_a_r_g_s...? Invokes _c_o_m_m_a_n_d in the scope of the most-specific class for the | object. This provides a way of accessing "virtual" functions from | within class methods. Normally, the commands at a certain class | scope refer to methods/procs in that class or in less-specific base | classes upward in the hierarchy. The vvvviiiirrrrttttuuuuaaaallll command moves the | scope _d_o_w_n_w_a_r_d to the most-specific class in the hierarchy, and then| invokes the method. If a class has methods that are redefined in | derived classes, this causes the most-specific method to be invoked.| Note that this is only needed when commands are invoked from within | a class; when commands are invoked at the global scope, they are | automatically executed in the scope of the most-specific class. AAAAUUUUTTTTOOOO----LLLLOOOOAAAADDDDIIIINNNNGGGG Class definitions need not be loaded explicitly; they can be loaded as needed by the usual Tcl auto-loading facility. Each directory containing class definition files should have an accompanying "tclIndex" file. Each line in this file identifies a Tcl procedure _o_r [_i_n_c_r _T_c_l] _c_l_a_s_s _d_e_f_i_n_i_t_i_o_n and the file where the definition can be found. For example, suppose a directory contains the definitions for classes "Toaster" and "SmartToaster". Then the "tclIndex" file for this directory would look like: _#### _TTTT_cccc_llll _aaaa_uuuu_tttt_oooo_llll_oooo_aaaa_dddd _iiii_nnnn_dddd_eeee_xxxx _ffff_iiii_llll_eeee_:::: _eeee_aaaa_cccc_hhhh _llll_iiii_nnnn_eeee _iiii_dddd_eeee_nnnn_tttt_iiii_ffff_iiii_eeee_ssss _aaaa _TTTT_cccc_llll _#### _pppp_rrrr_oooo_cccc_eeee_dddd_uuuu_rrrr_eeee _oooo_rrrr _[[[[_iiii_nnnn_cccc_rrrr _TTTT_cccc_llll_]]]] _cccc_llll_aaaa_ssss_ssss _aaaa_nnnn_dddd _tttt_hhhh_eeee _ffff_iiii_llll_eeee _wwww_hhhh_eeee_rrrr_eeee _tttt_hhhh_aaaa_tttt _#### _eeee_nnnn_tttt_iiii_tttt_yyyy _iiii_ssss _dddd_eeee_ffff_iiii_nnnn_eeee_dddd_.... _TTTT_oooo_aaaa_ssss_tttt_eeee_rrrr _TTTT_oooo_aaaa_ssss_tttt_eeee_rrrr_...._tttt_cccc_llll _SSSS_mmmm_aaaa_rrrr_tttt_TTTT_oooo_aaaa_ssss_tttt_eeee_rrrr _SSSS_mmmm_aaaa_rrrr_tttt_TTTT_oooo_aaaa_ssss_tttt_eeee_rrrr_...._tttt_cccc_llll The auto-loader must be made aware of this directory by appending the directory name to the "auto_path" variable. When this is in place, classes will be auto-loaded as needed when used in an application. Note: the usual "auto_mkindex" procedure used to generate the "tclIndex" file does not, by default, recognize [[[[iiiinnnnccccrrrr TTTTccccllll]]]] class definitions; however, it can be modified to do so. Such a modification is included in the "library" directory in the usual distribution for [[[[iiiinnnnccccrrrr TTTTccccllll]]]]. KKKKEEEEYYYYWWWWOOOORRRRDDDDSSSS object-oriented, class PPPPaaaaggggeeee 11110000